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ABSTRACT 

Software development has been characterized by severe cost overruns, schedule slippages and an 
inability to size, cost and determine the development time early in the feasibility and functional 
design phases when investment decision must be made. Managers want answers to the following 
questions: Can I do it? How much will it cost? How long will it take? How many people? What’s 
the risk? What’s the trade-off? This portion of the paper shows how to size the project in source 
statements (S s ), how to relate the size to the management parameters (life cycle effort (K) and de- 
velopment time (t d )] and the state-of-technology (C^) being applied to the problem through the 
software equation, S s = C^ K 1 '' 3 tj 4 '' 3 . The software equation is then solved using a constraint 
relationship K = IVD lt d 3 , wherelVDl is the magnitude of the difficulty gradient empirically found 
to be related to system development characteristics measuring the degree of concurrency of major 
task accomplishment. Monte Carlo simulation is used to generate statistics on variability of the ef- 
fort and development time. The standard deviations are used to make risk profiles. Finally, having 
the effort and development time parameters, the Rayleigh/Norden equation is used to generate the 
manpower and cash flow rate at any point in the iife cycle. The results obtained demonstrate that 
engineering quality quantitative answers to the management questions can be obtained in time for 
effective management decision making. 

BACKGROUND AND APPROACH 

Overthe past four years the author has studied the manpower vs time pattern of several hundred 
medium to large scale software development projects of different classes. These projects all exhibit 
a similar life cycle pattern of behavior — a rise in manpower, a peaking and a tailing off. Many of 
these projects (and all the large ones) follow a time pattern described by the life cycle curves of 
Norden (7,8) which are of the general Weibull class and more specifically the Rayleigh form, 

y = K/t d 2 . t . e /^d , where y is the manpower at any time t; K is the area under the curve and 
is the nominal life cycle effort in manyears; t d is the time of peak manpower in years and corre- 
sponds very closely to the development time for the system. 

Even though large systems seem to follow this general pattern, some small systems do not. They 
seem to have a more rectangular manpower pattern, The reason for this is that the applied man- 
power pattern is determined by management and by contractual agreements. Many small projects 
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are established as level-of-effort contracts — hence rectangular manloading. For large projects this 
is generally inadequate because managers have a poor intuitive feel for the resources to do the job. 
Accordingly, they tend to respond to the needs of the system reactively. This results in time lags 
and underapplication of effort at some instant in time, but the effect is a reasonably close approxi- 
mation to Rayleigh manloading. 

The author has shown in earlier works (5-6) that there is a Rayleigh law at work. It is the 1st sub- 
cycle of the overall development curve called the design and coding curve (detailed logic design and 
coding). This is also a manpower curve that is proportional to the analyst and programmer man- 
power — the direct productive manpower. This curve is denoted y, . Its form is 

Yi = K/t d 2 t e ' 3 * /t d 2 (MY/YR) when related to the original definition of K and t d for the overall 
burdened life cycle curve. When this curve is multiplied by the average productivity (PR) for the 
project it yields the rate of code production. 

dS s = S s = 2.49 PR y, , where the 2.49 is 
dt 

necessary to account for the definition of productivity as a burdened number (i.e., includes over- 
head and support activities). Now the time integral of the rate of code production yields the total 
number of source statements, 

oo oo 

S =/ ill! dt = PH 2.49 / y, dt 
s o dt 0 

S s =TR . 2.49.K/6. 

The author has found that the PR is related to the Rayleigh parameters K and t d in the following 
manner (6): 

PR = C n (K/t d 2 )" 2/3 where the term K/t d 2 has been defined as the system difficulty in terms of 
effort (K) and time (t d ) to produce it and C n is a quantized constant defining a family of such curves. 
C n is a channel capacity measure in the information theory sense, but in a more practical sense, it 
seems to be a measure of the state-of-technology being applied to a particular class of system. 

Substituting for PR, we obtain the software equation: 

S s = 2.49 C n (K/t d 2 ) - 2 / 3 K/6 

S s =^42C n KK‘ 2 / 3 t d 4 / 3 

S s = Cj^ K 4 / 3 t d 4 / 3 , where has now 
subsumed 2^2 C n . 

Having this expression which now relates the product in source statements to the Rayleigh man- 
power parameters (which are also the management parameters), we turn to a practical way in which 
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to estimate the size (S s ), effort (K) and development time (tj) of a software project early in the re- 
quirements and specification phase of the project. This will let us answer the management questions 
necessary for effective investment decisions for the software project. 

We will do this in the form of a case history for a project we will call SAVE. First, we will show a 
way to obtain a good estimate of the number of source statements. We’ll plot the software equa- 
tion and establish a feasible region for our development time parameters, we will impose a con- 
straint relation involving K and (t^). We will do a Monte Carlo simulation to generate variances for 
K and (tj). With these numbers in hand, we can then do a trade-off analysis, pick a reasonable effort 
(cost) time combination and complete our translation into quantitative answers to the management 
questions. The answers we obtained will be close to optimal for the given constraint and, moreover, 
we will automatically have a sensitivity and risk profile. 

INITIAL SIZING 

Given the broad, preliminary design of SAVE consisting of the processing flow of the major func- 
tions and the estimates by the designers of the size range of the major functions, we can make a 
preliminary estimate of the development time, development effort and development cost to build 
the system. 

The input data from the project team are in the form of size ranges for each major function. Three 
or four team members estimated the size of each function as follows: 

— Smallest possible size (in source statements) — a 
— Most likely size - m 
— Largest possible size - b 

These were averaged for each function and resulted in the first 3 columns of Table 1 . This was in 
effect a Delphi polling of experts and their consensus. (Having done this with several groups of sys- 
tems engineers, it is interesting to note that they are very comfortable with this procedure.) 

Note that this results in a broad range of possible sizes for each function and that the distribution is 
skewed on the high side in most cases. This is typical of the Beta distribution, the characteristics of 
which are used in PERT estimating. We adopt the PERT technique to get an overall system size 
range and distribution. 

1. An estimate of the expected value of a Beta distribution is: 

E, = a + 4m + b 
6 

The overall expected value is just the sum of the individual expected values. 

N 

E = Z Ej . 

1 = j L. Putnam 
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This is the sum of the fourth column of Table 1 (98475 S $ ), 


2. An estimate of the standard deviation of any distribution (including Beta) is the range 
within which 99% of the values are likely to occur divided by 6, i.e, 

a ] = |b-a| /6 

The overall standard deviation is the square root of the sum of the squares of the individual stan- 
dard deviations, i.e., 

%,= (^A 1/2 

V" / 

This results in a much smaller standard deviation than one would “guess” by just looking at the in- 
dividual ranges: the reason is that some actuals will be lower than expected (Ej); others will be 
higher. The effects of these variations tend to cancel each other to some extent. This cancelling 
effect is best represented by the root of the sum of squares criterion. 


The result is 

A 

E = 98475 source statements 
# tot = ± 7081 source statements 

and the 99% range is 77,000 — 120,000 S s , or we are 99% sure that the ultimate size will be in this 
range if the input estimates do not change. Of course, if the input estimates change, we should redo 
our calculations and revise the results accordingly. 


Major Function 

Least 

a 

Most 

Likely 

m 

Most 

b 

■ 

Standard 

Deviation 

a i 

Maintain 

8675 

13375 

18625 

13467 

1658 

Search 

5377 

3988 

13125 

9109 

1258 

Route 

3160 

3892 

8800 

4588 

940 

Status 

850 

1425 

2925 

1579 

346 

Browse 

1875 

4052 

8250 

4389 

1063 

Print 

1437 

2455 

6125 

2897 

781 

Cser Aids 

6875 

• 10625 

16250 

10938 

1663 

Incoming Msg 

5830 

3962 

17750 

9905 

1987 

Sys Monitor 

9375 

14625 

28000 

16979 

3104 

Sys Mgt 

6300 

13700 

36250 

16225 

4992 

Comm Proc 

3875 

3975 

14625 

9400 

1458 





98475 
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DEVELOPMENT TIME-EFFORT DETERMINATION 


Table 2 is a result of using the software equation which relates the product in source statements 
to the effort, development time and state-of-technology being applied to the project. The equation 
is derived partly from theory and partly from an empirical fit of a substantial body of productivity 
data, rhe form of the equation is: 


S s =C k K>/3t d 4 /3 

where S s is the number of end product delivered source lines of code, an information measure. 

C k is a state-of-technology constant. For the environment anticipated for SAVE this constant is 
1 0040. C k can be determined by calibration against the software equation using data from proj- 
ects developed by the same software house using similar technology and methods. 





Fastest 

Risk Biased 


S s 

Dev Effort (MY) 

*d 

Dev Effort 
(MY) 

t d + .4yr 

Dev Effort 
(MY) 

-3<r 

77000 

11.28 

(S.564M) 

1.63 

25.80 

(S1.29M 

2.03 

10.71 

(S.55M) 

-lcr 

91394 

18.86 

(S.943M) 

1.75 

32.16 

(S1.61M) 

2.15 

14.12 

(S.71M) 

E 

98475 

23.59 

(S1.18M) 

1.81 

35.40 

(S1.77M) 

2.21 

15.91 

(S.796M) 

+ 1<7 

105556 

29.05 

($1.45M) 

1.86 

38.71 

(S1.84M) 

2.26 

. 17.77 
(S.89M) 

+3<r 

1 20000 

42.69 

(S2.135M) 

1.97 



45.55 

(S2.28M) 

2.37 



21.77 

(S1.09M) 


Table 2. Assumptions: On-Line interactive development; top-down, structured programming; 
HOL; contemporary development environment. = 10040, Standalone system — IVDI = 15. 
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K is the life cycle effort in man years. This is directly proportional to development effort 

(Dev Effort = .4K) and cost (S/MY . K = SLC cost; S/MY . (,4K) = $ Dev). 

tj is the development time in years. This corresponds very closely to customer turnover. 

Figure 1 shows a parametric graph of this equation. 

Table 2 presents three scenarios for 5 different points in the size distribution curve. The expected 
case is given in the row labelled E. The column under t^ = 2 years gives a nominal development 
effort of 23.59 man years, S1.18M cost (@ $50,000/MY) to do 98475 source statements. 

The fastest (or minimum) possible time for 98475 source statements is 1.81 years. The corres- 
ponding development effort is 35.4 MY, and cost of $1.77 million. The assumption here is that 
the system is a stand alone and the gradient condition of 1701 = 1 5 cannot be exceeded. 


The risk biased column is based on deliberately adding time (.4 of a year) to the minimum time to 
increase the probability of being able to deliver the product at the contract specified date. This 
biasing is to allow for external factors such as late delivery of a computer, an average number of 
requirements changes during development, etc. In the case of 98,475 source statements, this would 
be 1.81 +.4 = 2.21 years. The corresponding expected development effort is 15.91 MY; $.8 million 
cost. Note that development effort and cost go down as time to do the job is increased. This is 
Brooks’ law at play. Conversely, there is no free lunch - if time is shortened the cost goes up> 


dramatical!} 


This can be illustrated by obtaining the trade off law from the software equation. Solve the software 
equation for K : 


s S = c k Kl/ 3 ‘d 4/3 = C k (Kt d 4 ) 1/3 



This is the trade-off law. In terms of development effort, E = .4K so 

E = 4 (^t) 3/ '“ 4 MY 


In our specific case 
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and we can trade-off between 2 years (contract constraint, say) and 1.81 years — the minimum time 
for our gradient constraint. 

PARAMETER DETERMINATION BY SIMULATION 

While Table 2 gives a fairly broad range of solutions that answer many “what if’ questions, it is an 
essentially deterministic solution ; that is, it assumes we know the input information exactly. Of 
course, we don’t. 

A better solution, then, is one in which we treat the uncertainties in our input information in ob- 
taining our solution. This is generally not feasible analytically, but is nicely handled by Monte Carlo 
simulation. In our case we do this by letting the input number of S s vary randomly about the ex- 
pected value (98,475) according to our computed standard deviation, = 7081, and letting the 

the stand-alone gradient ( IVDI = 15) vary within the statistical uncertainty of its measured (com- 
puted) value ( o j) = 2). 

We then run the problem on the computer several thousand times with these random variations in 
parameters and generate the statistics of the variation in our answer. This is a much better measure 
of what is likely to happen as a result of the uncertainties in the problem. 

The results of the simulation are given in the next table. Notice that the simulated estimated de- 
velopment effort is the same as the expected deterministic value and the development time is also 
the same. This is as it should be. 'The simulation produces the right expected values. The real value 
in the simulation is that it produces a measure of the variation in effort and in development time 
which we can usedto construct risk profiles. 

SAVE SIMULATION ~ ~ ~ 1 


INPUT : 85 = 98475,0^ = 7081 

D = 1 5, aj) = 2 

= 10040, N = 2170 iterations 

RESULTS : 

Expected development time = 1.81 yrs. 
o, development time = ± .063 yrs. 
Expected development effort = 35.1 MY 
a, development effort = ± 3.77 MY 


Table 3. 


MAJOR MILESTONE DETERMINATION 

The results of the simulation determination of the development time are used to generate the major 
milestones of the project. 
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These milestones relate to the coupling of subcycles of the life cycle to the overall project curve 
(5). Examination of several hundred systems shows this coupling is very stable and predictable. The 
empirical milestones resulting from these earlier studies shows the following scaling. 


Event 

Critical Design Review 
Systems Integration Test 
Prototype Test 
Start Installation 
Full Operation Capability 


Milestone Fraction of 
Development Time, t^ 

A3 

.67 

.80 

.93 

1.0 


Table 4 converts this to the appropriate descriptors and actual time schedule for this project. 


SAVE MILESTONES (t H 

= 1.81 years) 

Event 

t/t d 

Time from start 
(months) 

CDR 

.43 

9 

Software S.I.T. 

.67 

15 

Hardware S.I.T. 

.80 

17 

Start Install. 
Start Accept. 

.93 

20 

Test 

Complete 

1.0 

22 

Accept. Test 

1.14 

25 


Table 4. 


RISK ANALYSIS 

The results of the SAVE simulation for development time, development effort and development 
cost can be shown in the form of probability plots. Assuming a normal (gaussian) distribution, all 
that is necessary is an estimate of the expected value (plotted at 50% level) and the standard devi- 
ation (plotted offset from the expected value at the 16% probability level) to generate the line. 
Then one can determine the probability of any value of the quantity in question. For ease 
of presentation, the plots are summarized in Table 5. 


% Probability 
that value will 
not be greater 
than 

Dev Time 

(t d > 

years 

Dev Effort 
(E) 

manyears 

Dev Cost 
PH II 
Millions 

1 

1.55 

25 

1.25 

10 

1.73 

30 

1.50 

20 

1.76 

32 

1.60 

50 

1.81 

35.1 

1.75 

80 

1.86 

38.5 

1.93 

90 

1.90 

40 

2.04 

99 

1.97 

45 

2.25 


Table 5. 
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The result for the development time is extremely important from a conceptual point of 
view. The small standard deviation is both a curse and a blessing. It says we can deter- 
mine the development time very accurately (o^/t d = 3.5%) but at the same time it tells 

us we have little latitude in adjusting the development time to meet contractual require- 
ments. 


For example, o t = .063 years is .063 (52) = ± 3.28 weeks; 3o^ =3 (3.28) 
we^cs; d d 

= ± 10 weeks 


± 9.83 
± 9.83 


So, if we add 30 to t d we will be 99% sure that t d will not exceed the actual value from random 
causes. This does not mean that requirements changes or late delivery of a computer will still per- 
mit the software to come in at ± 10 weeks of the expected time. These are external factors that 
will change t d and must be specifically accounted for. 

This is the curse. The system is very sensitive to external perturbations and these will generally 
cause development time increments greater than 2 or 3 a t (a 90 day delay in test bed computer 
delivery, say). d 

But, knowing this great time sensitivity, management can use it effectively in planning and con- 
tracting so that risk is always acceptable. The major point is: time is not a free good. Develop- 
ment time cannot be specified by management. 

MANPOWER AND CASH FLOW PATTERN 


Now that we have the parameters for development effort and development time we can generate 
the manloading and cash flow pattern for the software development period (and even the life cycle, 
if we choose). The Rayleigh/Norden equation gives the instantaneous manpower. 

2 

y = K/t d 2 . t . e _t /2t d 2 MY/YR 

for the software development effort (Phase III). The cash flow is just the average dollar cost/MY 
times y. _ _ 


Cash Flow Phase II = S/MY . y $/YR 

Table 6 combines the software development effort (Phase II) with the initial design and system 
specification (Phase II) overlap and the hardware integration and test effort. The column labelled 
total adds the separate efforts together at each time period to show the total people on board. The 
cash flow rate is the annualized spending rate at that instant in time (assuming an average burdened 
cost/MY of $50,000). The last column gives the cumulative cost at each two month interval. 
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CASHFLOW 

RATE 

($ MIL/YR) 

SUM COST 
($ MIL.) 

.50 

— — 

.65 

.096 

.80 

.217 

.90 

.358 

.95 

.513 

1.15 

.888 

1.25 

.896 

1.45 

1.383 

1.60 

1.654 

1.65 

1.933 

1.70 

2.225 

1.80 

2.405 

1.20 














MANPOWER 

(MY/YR) 



(MONTHS) 


Figure 2 
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CONCLUSION 


We have shown that the management questions posed at the beginning can be answered quantita- 
tively to acceptable engineering accuracy for a software project during the specification prepara- 
tion phase. We need only know the state-of-technology we are going to apply to the development, 
estimate the number of lines of code using the PERT techniques, and use the software equation 
with a constraint relationship to solve for the management parameters (K,^) of the Rayleigh/Norden 
equation. Simulation provides suitable statistics for risk estimation. 
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WHAT DO WE WANT TO KNOW ABOUT QUANTITATIVE 
SOFTWARE MANAGEMENT? 


GEMENT 

METERS 



HOW MANY PEOPLE 

HOW LONG 

HOW MANY DOLLARS 

MANPOWER (MANLOADING AT ANY POINT IN TIME) 

CASH FLOW (SPENDING RATE) 

RISK OR UNCERTAINTY ASSOCIATED WITH EACH OF THESE 
TRADE-OFFS 


WHAT DO WE NEED? 


• A SMALL SET OF EARLY (PERHAPS GROSS) SYSTEM CHARACTERISTICS 

THAT 

• MAP INTO THE MANAGEMENT PARAMETERS 

• A MEANS TO UPDATE (AT ANY POINT IN LIFE-CYCLE) AND CONTROL. 
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WHAT IS A LIFE CYCLE? 



t 

BEGINNING Til 


{ 


CUMULATIVE 

EFFORT 

OR 

DOLLARS 

OR 

COMPLETE 



T 
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THE SOFTWARE LIFE CYCLE 


MANPOWER (PEOPLE/YR) 

♦ II 




DEVELOPMENT t d MODIFICATION AND ENHANCEMENT 

WORK % 40% OF TOTAL EFFORT j | WORK £ 60% OF LIFE CYCLE EFFORT 


V. 


APPLICATION SOFTWARE: 

SOLVING THE SIZING ESTIMATING PROBLEM 


i— • FEASIBILITY SIZING 

- ESTABLISH BOUNDS ON SIZE (DELPHI. BAYESIAN 

9 . INFERENCE. SIMULATION) 

- ESTABLISH BOUNDS ON EFFORT, $, DEV. TIME (±75-100%) 


V 

r » DECISION SIZING (< ±25% EFFORT, $. t d ) 

- PRELIMINARY DESIGN DONE (KNOW MAJOR FUNCTIONS 
S s ESTIMATE, TECHNOLOGY STATE POSSIBLE) 


r- CONVERGE TO TRUE BEHAVIOR 

- FIT REAL DATA (ADAPTIVE FILTERING) 


20-40% 

of 

software 

work 


MANPOWER 

(PEOPLE/YRI 


p- • CONTROL 

- FIT REAL DATA (MINOR 
PARAMETER ADJUSTMENT) 


60 80% OF SOFTWARE 
WORK 


SYSTEMS 

DEFINITION 


FUNCTIONAL 
DESIGN. SPEC. 


II 

II 


DEVELOPMENT 


OPERATION AND MAINTENANCE 


(CUSTOMER 

OR 

CONTRACTOR) 


(CONTRACTOR) 


(CUSTOMER) 



FUNCTIONAL 
SYSTEMS DESIGN. SPEC. 
DEFINITION 


DEVELOPMENT 
WORK AT 10% OF 
TOTAL EFFORT 


MODIFICATION AND ENHANCEMENT 
WORK AT 40% OF LIFE CYCLE EFFORT 


THE SOFTWARE LIFE CYCLE 
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MANPOWER UTILIZATION CURVE 
y =2 Kata -at 2 


MAN MONTHS 
250 r 


DISTRIBUTION OF THE SAME TOTAL UTILIZED EFFORT, 
VARYING THE TIME REQUIRED TO REACH PEAK MANPOWER. 
K * 1000 FOR ALL CURVES 


a s .0556 


a * 0200 



K = TOTAL EFFORT UTILIZED 

os parameter determining 

TIME OF PEAK MANPOWER 
ELAPSED TIME FROM START 


a*. 0102 




2 14 1 

1 y max = 3 

t * 1 _ 

T y max *5 


10 12 14 16 18 20 22 24 26 

MONTHS 


y max -7 


SHAPE OF EFFORT DISTRIBUTION FOR CONSTANT TIME-TO-PEAK 
BUT DIFFERENT TOTAL EFFORT UTILIZATION. 

MAN MONTHS a *.02 FOR ALL CURVES 
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WHY RAYLE f Gfl/NOROb'N? 


EVEN THOUGH OVERALL MANPOWER PATTERN OFTEN RESEMBLES RAYLE IGII/NORDEN FORM -- 


• IT DOES NOT HAVE TO -- MANAGEMENT DECIDES THAT. 

• BUT RAYLEIGH PATTERN IS OPTIMAL -- SO IT IS THE BEST MANAGEMENT CHOICE . 

• WHAT DOES HAVE TO BE RAYLEIGH IS THE CODE PRODUCTION RATE (S $ ). 



p— OEVEIOPHENI ~ OPERATION 4 HA I HI (NANCE 

• THE SOFTWARE EQUATION IS BASED ON THE DESIGN AND CODING CURVE (Y ( -u S $ ). 

IT MAPS INTO THE OVERALL MANLOADING CURVE FOR LARGE PROJECTS (Y,. S $ - K, tj , t). 
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THE SOFTWARE EQUATION 




“ • “ • _"k /-3t 2 \ 

S c = / S c • dt = / PR • y, • dt = PR • { ■ t . exp( — • dt 

s o s o 1 • t d 2 \ t d 2 ) 


1 4 



OUTPUT STATE OF INPUT 

TECHNOLOGY 
PARAMETER 


• S s IS THE PRODUCT (OUTPUT) - DEPENDENT ON SYSTEM CHARACTERISTICS 

• C K IS THE CHANNEL CAPACITY CONSTANT - QUANTIZED AND TECHNOLOGY DEPENDENT 

(MACHINE THRU-PUT, TOOLS, LANGUAGE) 

• K , t d ARE THE MANAGEMENT PARAMETERS (INPUT) - K, MAY BE TRADED-OFF TO MATCH SYSTEM 

AND TECHNOLOGY CHARACTERISTICS AND POSSIBLY CONTRACTUAL CONSTRAINTS 
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DEVELOPMENT TIME t d (YEARS) 




DEVELOPMENT TIME t H (YEARS) 




TRADEOFF LAW 


, (COROLLARY TO BROOKS’ LAW) 


NUMBER OF SOURCE STATEMENTS IS FIXED 

C 2 NOW SUBSUMES THE AVERAGE $ COST/MY 

• SUBJECT TO THE GRADIENT CONSTRAINT 

(CANNOT EXCEED CAPABILITY OF ORGANIZATION AND ITS TECHNOLOGY) 
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-&> 

I'J 


LARGE 



RESPONDS LATE TO SYSTEM OEUAmtS 



MULT I PIE SUPS, 

ADI) MANPOWER UllfN SLIPS OCCUR 


ON OF MANPOWER APPLICATION 
1 of 2 


SMALL 


NAIVE BEGINNER 



OVERRUN AND SLIPPAGE 


PLAN THE JOB 



ON TIME 

COSTS TOO MUCH 
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VARIOUS MANLOAD i MG PATTERNS 








ARON (IBM) LIFE CYCLE CURVE IS NOT INCONSISTENT 



CROSS-HATCHED AREA REPRESENTS 

- EXTENSION 

- ENHANCEMENTS 

THIS WORK IS NORMALLY DONE BY CUSTOMER OR CUSTOMER REPRESENTATIVES 
(NOT SEEN BY SOFTWARE HOUSE). 
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THE INPUTS NECESSARY TO FORCAST SOFTWARE COSTS 

NO. OF FILES SYSTEM WILL HAVE 

NO. OF OUTPUT FORMATS SYSTEM WILL HAVE 

NO. OF APPLICATION SUBPROGRAMS SYSTEM WILL HAVE 

NO. OF SOURCE STATEMENTS SYSTEM WILL HAVE 

AVERAGE NO. OF SOURCE STATEMENTS PER SUBPROGRAM 

AVERAGE COST PER MAN YEAR OF EFFORT 

AVAILABILITY OF COMPUTER TEST TIME THROUGHOUT DEVELOPMENT - 
HOURS/MONTH 

DEVELOPMENT ENVIRONMENT 

- INTERACTIVE? 

- BATCH? 

- DEDICATED TO DEVELOPMENT, OR PRODUCTION WORK ALSO BEING DONE? 
MODERN SOFTWARE ENGINEERING TOOLS TO BE USED 

TYPE SYSTEM (BUSINESS, C&C, SCIENTIFIC, REAL-TIME, ETC.) 

TECHNOLOGY CONSTANT CALIBRATION DATA (DEV EFFORT, DEV TIME, SIZE 
IN SOURCE STATEMENTS (LESS COMMENTS) FOR ONE OR MORE PREVIOUS 
SIMILIAR SYSTEMS THAT USED A SIMILAR DEVELOPMENT ENVIRONMENT AND 
TOOLS) 
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DATA TO CAPTURE DURING DEVELOPMENT TIME 


• RATE OF CODE PRODUCTION (S s /YR) 

• MANPOWER (RATE) DEVOTED TO DESIGN AND CODING (y j ) 

• CUMULATIVE CODE PRODUCTION AT TIME, t (S s (t)) 

• CUMULATIVE PEOPLE ASSIGNED TO DESIGN AND CODING AT TIME T 

(y l (t» 

• TOTAL CUMULATIVE PEOPLE (INCLUDING ALL INDIRECT EFFORT AND OVER- 
HEAD) AT TIME t (y(t)) 

• ACTUAL TIMES WHEN CRITICAL EVENTS START 

- CRITICAL DESIGN REVIEW 

- SYSTEM INTEGRATION TEST 

- PROTOTYPE TEST ( 1 ST ON-SITE, FULL SCALE TEST) 

- INITIAL OPERATIONAL CAPABILITY 

- CUSTOMER TURNOVER (IF DIFFERENT FROM I.O.C.) 

• COMPUTER TEST TIME USED PER MONTH (CH/ MO ) 

• CUMULATIVE COMPUTER TEST TIME USED AT TIME t, (CH) 
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REASONS WHY SOFTWARE DETERIORATES 


• RECOGNITION OF ORIGINAL DESIGN FAULTS. 

• DISCOVERY OF BUGS/ERRORS. 

o EVOLUTION OF A LEARNING USER WHO DEVELOPS HIS UNDERSTANDING OF 
THE “REAL” PROBLEM AND UPGRADES HIS REQUIREMENTS BASED ON OPER- 
ATIONAL EXPERIENCE. 

• CHANGES IN THE APPLICATION ENVIRONMENT AS A RESULT OF BUSINESS, 
ACCOUNTING AND GOVERNMENT REQUIREMENTS. 

• CHANGES IN COMPUTER TECHNOLOGY - BOTH SYSTEMS SOFTWARE AND 
HARDWARE. 


Werner L. Frank 
in COMPUTERWORLD 


• m “MAINTENANCE” (ENHANCEMENTS, MODIFICATIONS, ERROR 
FIXING) 
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DATA REQUIRED DURING OPERATIONS AND MAINTENANCE PHASE 


• MANPOWER DURING DEVELOPMENT (MY/yr) 

• TOTAL DEVELOPMENT EFFORT (MY) 

• DEVELOPMENT TIME (FROM START OF DESIGN AND CODING TO CUSTOMER 
TURNOVER) (t d ) 

• ELAPSED TIME FROM START TO START OF CRITICAL MILESTONES 

• ACTUAL MANPOWER (CONTINUOUSLY AS A FUNCTION OF TIME) (y act ) 

• MAINTENANCE DATA 

- NO. ENHANCEMENTS STARTED/MO. 

- NO. EMERGENCY FIXES STARTED/MO. 

- NO. VALID ERRORS FOUND/MO. 

- NO. ENHANCEMENTS/FIXES DEFFERED/MO. 

- NO. MODULES CHANGED/MO. 

• SIZE OF SYSTEM - SOURCE STATEMENTS (CONTINUOUSLY) (S s ) 

• CUMULATIVE NO. MODULES/SUBPROGRAMS CHANGED SINCE TURNOVER (t d ) 
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SOFTWARE AXIOMS FOR PROJECT MANAGERS 


• SOFTWARE DEVELOPMENT HAS ITS OWN CHARACTERISTIC BEHAVIOR 

• SOFTWARE DEVELOPMENT IS DYNAMIC - NOT STATIC 

• PRODUCTIVITY AND CODING RATES ARE CONTINUOUSLY VARYING - NOT 
CONSTANT 

• PRODUCTIVITY RATES ARE A FUNCTION OF THE SYSTEM DIFFICULTY - 
MANAGEMENT CANNOT ARBITRARILY INCREASE PRODUCTIVITY. MANAGE- 
MENT CAN FAVORABLY INFLUENCE THIS BY PROVIDING SUFFICIENT TIME. 

• BROOKS’ LAW GOVERNS - TIME AND MANPOWER ARE NOT FREELY INTER- 
CHANGEABLE. (SHORTENING THE “NATURAL” DEVELOPMENT TIME OF A 
SYSTEM IS VERY COSTLY - AND MAY BE IMPOSSIBLE) 

• THERE IS A SOFTWARE LAW THAT MUST BE OBEYED - OTHERWISE SLIPPAGE 
AND OVERRUN ARE INEVITABLE. 

• KEEP A RECORD OF WHAT HAPPENED, WHEN AND HOW MUCH - IT WILL HELP 
NEXT TIME. 
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MENU 

( WHAT WE CAN DO NOW ') 


• PARAMETER ESTIMATION 

- LIFE CYCLE SIZE (COST) (K) 

- DEVELOPMENT TIME (t d ) 

• MANPOWER VS. TIME 

• CASH FLOW VS. TIME 

• COMPUTER TIME VS. TIME 

• RISK ANALYSIS 

- COST 

- MANPOWER 

- TIME 

• UPDATING ESTIMATES FROM ACTUAL DATA (BOX’S METHOD) 

• DYNAMIC MODELING OF CHANGES TO RQMTS, SPECS 

• SIMULATION OF MANPOWER, CASH FLOW 

• LIFE CYCLE COST/BENEFIT ANALYSIS 

• AGGREGATION OF SYSTEMS TO CONTROL TOTAL EFFORT OF SOFTWARE 
HOUSE 

• FORECAST INTERNAL MANPOWER GENERATION RATE OF SOFTWARE HOUSE 
DOING MOSTLY MAINTENANCE WORK 
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WHAT DO WE NEED TO 
ANSWER THE MANAGEMENT QUESTIONS? 


ESTIMATES OF: 


• NUMBER OF SOURCE STATEMENTS 

• TECHNOLOGY CONSTANT 

• ONE OR MORE CONSTRAINTS: 

- MANPOWER 

- MAXIMUM TIME 

- MAXIMUM COST 

- (MAXIMUM DIFFICULTY) 

- (MAXIMUM DIFFICULTY GRADIENT) 

ACTUAL DATA 


• DATA STREAM FROM PROJECT WHEN UNDERWAY TO DYNAMICALLY 
CONVERGE TO TRUE SYSTEM BEHAVIOR 
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THE LIFE CYCLE METHOD 
CAN ANSWER THE MANAGEMENT 
QUESTIONS: 


• CAN I DO IT? 

• HOW MANY DOLLARS? 

• HOW LONG? 

• HOW MANY PEOPLE? 

• WHAT’S THE TRADE OFF? 

• WHAT’S THE RISK? 
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PROJECT DURATION (MONTHS) VS QSL0C 



LERST SOURRES BE5T FIT 
Y = .*107731 1 X f . 3*19 1 63) 
R = .700265 
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